Computers store, share and manipulate digital products, e.g., digital information, data, content or programming. Digital products can be replicated accurately and shared widely among many computer systems. Computers share or receive digital products in a variety contexts. Digital products can be stored, exchanged and delivered by way of magnetic (floppy diskette) or optical (CD-ROM) storage devices. Computers operating in network environments, e.g., in a local area network, a wide area network, or the well known Internet global communications system, pass digital products back and forth freely and often in great volume. Wide-spread replication and distribution of digital products supports new methods of digital product manufacturing and distribution, i.e., digitally stored items can be copied and distributed electronically outside the traditional methods of product manufacture and distribution.
Because digital products can be electronically replicated and distributed widely, a question of authenticity often arises with respect to certain digitally stored items. For example, a person purchasing a digital product via the Internet wants assurance of the authenticity of the product, i.e., that the digital product purchased is in fact what it purports to be and originates from the purported source without corruption. A digital product publisher needs authentication of ownership for persons requesting technical support or upgrading to a next version of a given digital product. Thus, persons purchasing a digital product want an authentic copy and publishers want only to support or allow upgrades relative to an authentic copy. The problem with digital products is that copies are identical to the original product and proving authenticity of source or authenticity of ownership of a given digital product goes beyond mere possession because possession can be achieved easily by copying.
Publishers of digital products have attached a physical certificate of authentication to digital products, e.g., a certificate physically attached to an associated product manual or product packaging. Such physical certificates of authentication include ornate artwork, e.g. complex and intricate graphics and holographic images, difficult to replicate. By providing such a physical certificate of authenticity with a digital product the publisher provides assurance that the associated digital product is intact and that it originates from the purported source. Thus, possession of such a physical certificate both corresponds to ownership and proves authenticity of source. Such physical certificates, however, cannot be used in electronic distribution schemes, e.g., where digital product distribution or purchase is by way of network or Internet interaction.
Digital products are subject to alteration or corruption, either intentionally or unintentionally. Unintentional corruption may occur during transmission or as stored on a particular distribution medium. Some data exchange or transmission mechanisms, e.g., electronic mail (E-mail) or file transfer protocols, introduce corruption by introducing additional characters, sometimes outside the ASCII code set. For example, some electronic mail transfers introduce characters at the beginning of each line. Other examples of corruption during file transfer include changes in line termination indicators, i.e., line feed, carriage return, and trailing spaces modified relative to the original document. Additional characters outside the ASCII code set are often apparent due to the effect such characters have on document appearance, especially for screen displays and when printing a document.
Intentional corruption may be malicious and may include placement of "viruses" within a digital product. Persons acquiring digital products want verification that a particular digital product has been not been altered either intentionally or unintentionally. For example, persons purchasing digital products want assurance that the digital product contains no viruses and that the product is intact, i.e., in its condition as originally published. Publishers of digital products want to deliver products intact and without corruption and want such product condition to be evident to the purchaser.
Furthermore, the need to prove authenticity of digitally stored items goes beyond electronic digital product distribution schemes. For example, a person obtaining certain information, e.g., an insurance quote, may wish to transmit such information to a third-party entity and be able to prove its authenticity. The person obtaining the information, the entity providing the information, and any third-party entity later receiving the information desire accuracy and authentication, i.e., each want to maintain the information intact and in an authenticatable form.
A common form of encryption used in network communication systems, e.g., the Internet, is by means of public/private keys, also known as public key infrastructure (PKI). The fact that public keys are public under PKI gives rise to the possibility of impersonation, i.e., someone making use of a public key and impersonating the entity associated with that key. A public key can be posted, purportedly belonging to one individual, but in fact created by another entity impersonating that individual.
Digital certificates have been employed in the context of encryption on the Internet to establish authenticity of public keys, i.e., to ensure that a given public key in fact belongs to the person purportedly associated therewith. This mechanism requires a trusted third party or "certification authority" (CA) responsible for checking each purported owner's claim to the published public key, i.e., requiring some proof of identification of persons publishing and posting public keys for purposes of encryption on the Internet. The certification authority then adds its digital signature to the public key and this, in effect, validates the public key. Compatibility, therefore, is necessary for wide spread and effective use of such digital certificates. Digital certificates issued by different certification authorities must be compatible in a context of encryption and decryption on a global communications network, i.e., the Internet. Software used to check and certify public keys must reference some standard protocol to be universally effective. One proposed standard form for digital certificates is commonly referred to as the "X.509" standard. This standard was originally part of a "X.500" series of standards, but has been extended to embrace a wide variety of Internet services such as E-mail, worldwide web protocols, user authentication, and electronic commerce. It is considered likely that the "X.509" standard will be accepted and rapidly incorporated into many products employing digital certificates based on the preliminary version of the "X.509" digital certificate standard. Such "X.509" certificates, however, do not possess the degree of robustness available under the present invention and currently are not equipped to do anything more than contain and verify the authentication of the holder.
Some software publishers, e.g., Microsoft, implement a "code signing" infrastructure where software developers "sign" their executables to authenticate such executables and ensure against corruption. Digitally signing executables in this fashion requires use of a software development kit (SDK) whereby the development process integrates the digital signing process. When the executable runs, it attempts to transact a verification process or transaction across the Internet. This is specifically for Internet-based programs. When the Internet verification transaction is triggered upon execution of the program, the program informs a certification authority (CA) that "I think I am Microsoft Windows", for example, and "this is my digital signature." The certification authority (CA) then independently calculates the correct digital signature. If the digital signatures match, i.e., the digital signature calculated at the certification authority and the digital signature presented by the executing program via the Internet verification transaction, then execution is allowed to continue. If the signatures don't match, then the executable has been corrupted or does in fact not originate from the publisher and is not what it purports to be. This mechanism authenticates that the software is in fact the product it purports to be and also that the product is being executed by the appropriate licensee. This mechanism requires use of an SDK, considered an undesirable intrusion into software development and desirably avoided when possible, and is limited to use in connection with executing a program. In other words, this authentication mechanism cannot be used generally for "static" data such as sound data, image data, or information generally.
The subject matter of the present invention provides a digital certificate format inherently assuring authenticity for both executable and static digital products embedded therein with protection against intentional or unintentional corruption. A person holding such a digital certificate holds a self-authenticating item which may be used to prove, for example, ownership, authentication of source, or unaltered state of an associated digitally stored item.